1. Field of the Invention
This invention relates generally to the deployment of applications in a multitier compute infrastructure, including those that host multitier applications. In a specific embodiment, it relates to the deployment of multitier applications that are based on a software component architecture, for example the Java 2 Platform, Enterprise Edition (J2EE)™ or .NET™ (J2EE is a Trademark of Sun Microsystems, Inc. and .NET is a trademark of Microsoft Corp.)
2. Description of the Related Art
With advances in computing, networking and software technology, an increasing number of applications are implemented on multitier compute infrastructures. For example, many Internet applications are implemented on a compute infrastructure that can be divided into three tiers: network, compute and application. One advantage of a multitier compute infrastructure is that different tiers can function at different “levels” while still interoperating with each other. In the three-tier example, the network tier operates at the “lowest” level of the infrastructure, the compute tier operates on top of that, and the application tier operates at the “highest” level. As a result, enterprise and other applications can be distributed among the tiers in a fashion that results in greater optimization and utilization of the infrastructure. For example, if a certain functionality is desired, it is not required that the functionality be implemented in a monolithic piece of software installed on a particular computer in a specific location within the network. Rather, the overall functionality can be distributed among different components within the multitier compute infrastructure.
Software component architectures, such as Java 2, Enterprise Edition (J2EE)™ and .NET™, are one approach that takes advantage of this flexibility. Software functionality is divided among different software components, each of which can run on a different computer located at a different network address. Each of the software components, computers and the network topology can be optimized for efficiency, security, scalability or other factors. For example, in the monolithic approach, a single code base and a single computer may be called upon to handle user requests for enhanced images, retrieve raw images from a large image warehouse and perform complex calculations to enhance the images. With the component approach, one software component and server could handle user requests, another could retrieve images, and a third could perform the calculations. Each of these can be optimized for its specific task and the same components can be used for more than one application. The overall enterprise is also more scalable since incremental capacity can be added by adding more components.
One drawback of the multitier and software component approaches is that, typically, many components are used in order to implement the desired functionality. For example, the software portion can be implemented by a large number of software components, each possibly executing on a different server, with the servers located on different networks. Software components may not even be executing on the same server each time. The real-time execution load can be load balanced among a server farm, for example. Currently, it is not uncommon for an enterprise application to have thousands of moving parts, many of which must work in tandem with each other in order for the overall enterprise application to function properly. In addition, multiple relationships between components exist within each tier, as well as across tiers of the compute infrastructure. For example, in the application tier, a web server and application server might work together to handle user requests. Cross-tier relationships, such as those linking the web server, DNS server and access router with each other, can be more complex but these often are the relationships that have a direct bearing on the availability, performance and security of the overall application.
Due to this increased complexity, managing a multitier compute infrastructure and the applications implemented on the infrastructure is more difficult. Tasks such as installing, configuring, activating, updating and monitoring enterprise functions are more complex compared to a situation where a monolithic piece of code executes on a single computer in a fixed network location. This is aggravated by the fact that the component approach can significantly reduce the development cycle time. It is not uncommon to have a J2EE™ application undergo ten to twelve updates each calendar year, with two of those being major upgrades to underlying functionality. In the meantime, it is increasingly more difficult to manage the application and its updates, including for example the tasks of merely installing and correctly configuring the updates.
Enterprise management capability has not kept pace with the shorter development cycle. For example, the task of updating the deployment of an application is largely a manual task, even today. Initially, the deployment team assembles the various software components that make up the application (i.e., the software packages), manually scans configuration files, and checks them against system documentation and physical network and compute configurations for consistency and completeness. The product of this effort is an inventory that should pinpoint omissions or conflicts prior to staging of the application. However, as the scope of enterprise applications expands and the different tiers become more distributed, the likelihood of uncovering all issues and of successfully deploying an application on the first try decreases.
Problems in an unsuccessful deployment typically are addressed by troubleshooting after the deployment. But troubleshooting can be time-consuming as the root causes may depend on complex cross-tier relationships. Not only does this add expense but it can also result in lost revenue as successful deployment of the application is delayed. In addition, cross-tier troubleshooting and, more generally, the management of a multitier compute infrastructure are most effectively performed by dedicated teams whose members are skilled in the application, compute and network tiers. It can be difficult to find these people and the IT headcount can be the limiting factor on scaling up an enterprise operation.
Part of the problem is that currently available management tools are mostly limited to a single tier. This is because many of these tools were developed for system administrators who were responsible only for a single tier. That is, one system administrator would be responsible for networking, another for computers, and another for software loaded on the computers. Single-tier tools would give some visibility into the tier for which the system administrator had responsibility, but did not, give visibility into cross-tier relationships or interactions. This is problematic since the trend is towards more numerous and more complex cross-tier relationships. For example, single-tier tools typically are not sophisticated enough to enable an application deployment team to anticipate and avoid problems in the deployment of applications since many of these problems may be the result of cross-tier relationships. An alternative is to manually piece together the required relationships, one tier at a time, and often using knowledge that resides only in some key employee's head. But this is both time-consuming and risky—for example, if the key employee were to leave the company.
Others are attempting to address these shortcomings. For example, some efforts focus on fast and/or automated installation of software. Loudcloud and CenterRun are two companies that appear to have efforts in this area. These tools automate some of the software installation process. For example, if a patch is to be distributed to 100 instances of an operating system, this tool might automate that process. However, in order to use this tool, someone must know where the 100 instances are located and how to properly configure the patches. Furthermore, if the patch itself requires an update in some other piece of software in order to run properly, someone must also remember that. Hence, these tools might reduce the cost and error of physically installing the patches, but they do not increase cross-tier visibility. Nor do they provide a complete ability to fully deploy an application. For example, these tools have limited or no capability to configure software once installed, to verify that the installation and configuration were performed properly, and/or to verify that the correct versions of supporting hardware and/or software are available.
Thus, there is a need for better tools and techniques for deploying applications in a multitier compute infrastructure, including applications that are implemented based on a software component architecture.